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1. Scope 

The Wireless Application Protocol (WAP) is a result of continuous work to define an industry-wide specification 
for developing applications that operate over wireless communication networks. The scope for the WAP Forum is 
to define a set of specifications to be used by service applications. The wireless market is growing very quickly, 
and reaching new customers and services. To enable operators and manufacturers to meet the challenges in 
advanced services, differentiation and fast/flexible service creation WAP Forum defines a set of protocols in 
transport, security, transaction, session and application layers. For additional information on the WAP architecture, 
please refer to "Wireless Application Protocol Architecture Specification " [WAP ARCH]. 

Multimedia Messaging Service (MMS) is a system application by which a WAP client is able to provide a 
messaging operation with a variety of media types. The service is described in terms of actions taken by the WAP 
MMS Client and its service partner, the MMS Proxy -Relay, a device that operates as a WAP Origin Server for this 
specialised service. This specification defines the operational flow of the messages that transit between the MMS 
Client and the MMS Proxy -Relay. The format of the specific messages is described in the "WAP MMS 
Encapsulation ProtocoV [MMSENCAPS]. 

For information about the MMS Architecture, the reader is advised to become familiar with the "WAP MMS 
Architecture Overview" [MMS ARCH] 
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2. Document Status 

This document is available online in the following formats: 
PDF format at http://www.wapforum.org/ . 

2.1 Copyright Notice 

© Copyright Wireless Application Forum Ltd, 2000. 

Terms and conditions of use are available from the Wireless Application Protocol Forum Ltd. web site at 
http :// www, wapforum . org/docs/copvright .htm 

2.2 Errata 

Known problems associated with this document are published at http://www.wapforum.org/ . 

2.3 Comments 

Comments regarding this document can be submitted to the WAP Forum in the manner published at 
http .7/ www . wapforum . org/ . 
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4. Definitions and Abbreviations 

4.1 Terminology 

The key words "MUST", "MUST NOT', "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described by [RFC21 19]. 

4.2 Definitions 

This section introduces a terminology that will be used throughout this document. 

Multimedia Messaging Service (MMS) 

A system application by which a WAP client is able to provide a messaging operation with a variety of 
media types. 

MMS Client 

The MMS service endpoint located on the WAP client device. 
MMS Proxy -Relay 

A server which provides access to various messaging systems. If the MMS Proxy -Relay operates as a 
WAP origin server it may be able to utilise features of the WAP system. 

MMS Server 

A server that provides storage and operational support for the MMS service. 
MMS M Link 

The interface between the MMS Client and its service partner, the MMS Proxy -Relay. 

Terminal 

A WAP client device. 
Transaction 

One or more message exchanges that collectively are considered logically separate from other message 
exchanges. 

WAP Origin Server 

A server that can deliver appropriate content upon request from a WAP client. 

4.3 Abbreviations 

For the purposes of this specification the following abbreviations apply. 

Email Electronic mail 

HTTP HyperText Transport Protocol 

IANA Internet Assigned Numbers Authority 

ID Identifier 

MIME Multipurpose Internet Mail Extensions 
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MM 


Multimedia Message 


MMS 


Multimedia Messaging Service 


OTA 


Over The Air 


PDF 


Portable Document Format 


PDU 


Protocol Data Unit 


T> TXT? 

RDF 


Resource Description Format 


RFC 


Request For Comments 


UArroi 


User Agent Profile 


URI 


Uniform Resource Identifier 


WAP 


Wireless Application Protocol 


WSP 


Wireless Session Protocol 


WTLS 


Wireless Transport Layer Security 


XML 


extensible Markup Language 
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5. Introduction 

This section is informative. 

The Multimedia Messaging Service (MMS) is intended to provide non-real-time messaging services to consumers 
utilising WAP technologies. It is an application level service that fits into the current WAP architecture. The 
following figure shows the general MMS Architecture. 




Figure 1 . MMS Network Diagram with MMS Client to MMS Proxy-Relay Link Highlighted 



The MMS client transactions described by this document take place on the interface labelled MMS M in the 
preceding diagram. 

The following figure presents an amplified view of the MMS W link It is built on top of the WAP architecture. In its 
role as an application, MMS provides for the delivery and services related to messaging and the data schemes that 
will permit presentation methods that provide for the multimedia user experience. These presentation methods are 
separate from MMS. 
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Figure 2. WAP Implementation of MMS M Interface 



This figure includes a few items that need to be described. The MMS Proxy -Relay is the network entity that 
interacts with the user mailbox and is responsible for initiating the notification process to the MMS Client. The 
WAP Gateway provides standard WAP services needed to implement MMS, these include: WSP invocation of 
HTTP methods, see [WAPWSP]; WAP PUSH services, see [PUSHARCH]; OTA security, see [WTLS]; and, 
Capability Negotiations, see [UAPROF]. 

The above figure also shows a payload that is carried by WSP and HTTP. This payload is described in the MMS 
Message Encapsulation [MMSENCAPS] document. It is expected that this data will be transported in its entirety 
between the MMS Proxy -Relay and the MMS Client. 

This description does not address issues related to the movement or acquisition of MM messages beyond the 
MMS Proxy -Relay as these are outside the scope of the MMS M link. 
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6. Introduction to MMS Transaction Model 

This section is informative. 

The MMS service is realised by the invocation of transactions between the MMS Client and the MMS Proxy - 
Relay. These transactions include information and affect state changes on these devices. This section introduces 
example transaction flows and section 7 describes each individual, logically separate transaction in more detail. 

The general transaction flows on MMSm for sending and retrieving MM messages do not depend on what type of 
client the MM message is sent to or received from. The other endpoint for the MM message may be another MMS 
Client served by the same or another MMS Proxy -Relay, it may be a client on a legacy wireless messaging system, 
or it may be an e-mail server. 

The following three figures provide general views of the MMSm transactions needed for: 1) an MMS Client to send 
an MM message and receive back a resulting delivery notice; 2) an MMS Client to perform immediate retrieval of a 
new MM message; and, 3) an MMS Client to perform delayed retrieval of a new MM message. The arrow labels in 
the following figures indicate the MMS messages (also known as MMS PDUs) exchanged during transactions. 
These messages are defined in detail in [MMSENCAPS]. 



Orig 
MMS Client 



Orig MMS 
Proxy-Relay 




MM f 
Recipient 



Interactions occurring beyond MMS M 
are not in this document's scope 



Figure 3. Example MMS M Transaction Flow- Sending 



A receiving MMS Client is said to perform immediate retrieval of a new MM message when it retrieves the data 
from the MMS Proxy -Relay before acknowledging the message notification. 
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Figure 4. Example MMS M Transaction Flow- Immediate Retrieval 



A receiving MMS Client is said to perform delayed retrieval of a new MM message when it first acknowledges the 
notification and at some later point retrieves the message from the MMS Proxy -Relay. 
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Figure 5. Example MMS M Transaction Flow - Delayed Retrieval 



If both endpoints for the MM message exchange are MMS Clients, the MMSm interface is involved both when the 
originating MMS Client sends the MM message to the originating MMS Proxy -Relay and when the target MMS 
Client retrieves the MM message from the target MMS Proxy -Relay. The following figure shows an example where 
both endpoints are MMS Clients and delayed retrieval is used. 
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Figure 6. Example MMS Transaction Flow- Delayed Retrieval 



As can be seen in these examples, several message exchanges occur on MMSm. These message exchanges can be 
considered to form the following logically separate transactions: 

• MMS Client Sending Message to MMS Proxy -Relay 

• MMS Proxy -Relay Sending Notification to MMS Client 

• MMS Client Fetching Message from MMS Proxy -Relay 

• MMS Proxy -Relay Sending Delivery Report to MMS Client 



These transactions are described in more detail in section 7. 



6.1 Error Considerations 

Section 7 also contains general error considerations for each transaction. For more specific information, the reader 
is referred to the [MMSENCAPS] and [WAPWSP] documents. The [MMSENCAPS] document also contains 
considerations for the case where the MMS Client and the MMS Proxy -Relay implement different versions of the 
MMS M protocol described here. 
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7. MMS Client Transactions 



This section is normative. 



The PDUs and information elements referred to in the following SHALL comply with the definitions in 
[MMSENCAPS]. 

7.1 MMS Client Sending Message to MMS Proxy-Relay 

The process for a client to send a message is built on top of the M-Send transaction. It provides the mechanism 
for the MMS Client to submit an MM message to the MMS Proxy -Relay and to get back information in response. 
The following Figure 7 gives an example of this transaction. 



Originating 
MMS Client 



MMS 
Proxy-Relay 



v M -Send. r eq 
taans=Tl ariHr 

'■aw.rnufflpart" 



~ trans; 



M-Send.conf - 
i5S T1. status, ref=Msg»u 



Figure 7. Example M-Send Transaction Flow 



7.1.1 Transaction Flow 

The MMS Client that wishes to send an MM message SHALL invoke a WSP/HTTP POST operation with the M- 
Send. req message embedded as the content body. This message is submitted using a URI that addresses the 
MMS Proxy -Relay that supports the specific MMS Client. 

The MMS Client SHALL compose a transaction ID for the submitted message. This transaction ID is used by the 
MMS Client and MMS Proxy -Relay to provide linkage between the originated M-Send . req and the response M- 
Send - conf messages. The value used for the transaction ID is determin ed by the MMS Client and no 
interpretation is expected by the MMS Proxy -Relay. 

Upon receipt of the M-Send - req message, the MMS Proxy -Relay SHALL respond to the WSP/HTTP POST with 
a response that includes the M-Send - conf message in its body. This response message SHALL provide a 
status code for the requested operation. If the MMS Proxy -Relay is willing to accept the request to send the 
message, the status SHALL be 'accepted' and the message SHALL include a message-ID that MAY be used for 
following activities that need to refer to the specific sent message (e.g. delivery reports). 

7.1 .2 Error Considerations 

Various error cases may exist. These include network faults, server faults and service faults. For network faults 
(e.g. server not available) or server faults (e.g. bad path) the MMS Client SHALL receive an error indication that 
relates to the WSP/HTTP error that was detected. These errors MAY be recoverable (e.g. MMS Proxy -Relay down 
temporarily) or may be more permanent in nature. Strategies for recovery or retry are beyond the scope of this 
document to address. 

Service errors are different. In these cases the MMS Proxy -Relay actually received the M-Send. req message and 
responds with an M-Send . conf message with the appropriate error code. 
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7.2 MMS Proxy-Relay Sending Notification to MMS Client 



To inform an MMS Client that an MM message is available and for it to return back information, a set of 
asynchronous messages, M-Noti f i cati on . i nd and M-Noti fyResp - i nd, are utilized. This provides the 
mechanism for the MMS Proxy -Relay to notify the MMS Client with certain factors about the new MM. This will 
let the MMS Client retrieve the MM. 



The MMS Proxy -Relay SHALL utilise the M-Noti f i cati on . i nd message when it needs to inform the MMS 
Client that a message is available for delivery. The M-Noti f i cati on . i nd message SHALL be sent by the 
MMS Proxy -Relay to the MMS Client using the WAP PUSH framework [PUSHARCH]. The M- 
Noti f i cati on . i nd message SHALL be sent as the message body of a [PUSHMSG]. The X-Wap -Application- 
Id message header of that push message MUST be set to 'x-wap-appiication:mms.ua' if the absoluteURI form of the 
app-id syntax is used, and MUST be set to l 4' if the app-assigned-code form of the app-id syntax is used. 

The information conveyed SHALL include an [RFC2396] compliant URI that will be used to actually retrieve the 
message in a subsequent operation by the MMS Client. Additional information about the message (e.g. message 
size, expiry) MAY be used by the MMS Client to determine its behaviour. For example, the MMS Client MAY 
delay the retrieval of the message until after a user confirmation if it exceeds a size threshold. 

The MMS Proxy -Relay SHALL compose a transaction ID for the notification message. This transaction ID is used 
by the MMS Client and MMS Proxy -Relay to provide linkage between the originated M-Noti f i cati on . i nd 
and the response M-Noti fyResp. i nd messages. The value used for the transaction ID is determined by the 
MMS Proxy -Relay and no interpretation is expected by the MMS Client. 

Upon receipt of the M-Noti f i cati on . i nd message, the MMS Client SHALL respond by invoking a 
WSP/HTTP POST operation with an M-Noti fyResp . i nd message embedded as the content body. This 
message is submitted using a URI that addresses the MMS Proxy -Relay that supports the specific MMS Client. 
The MMS Client SHOULD ignore the associated WSP/HTTP POST response from the MMS Proxy -Relay. 

The M-Noti fyResp - i nd response message SHALL provide a message retrieval status code. The status 
1 ret ri eved ' SHALL be used only if the MMS Client has successfully retrieved the MM message prior to 
sending the Noti fyResp . i nd response message. 



MMS 
Proxy-Relay 



Target 
MMS Client 





Figure 8. Example MMS Notification of MM message to Target Client 



7.2.1 Transaction Flow 
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7,3 MMS Client Fetching Message from MMS Proxy-Relay 



The operation for retrieval of the MM message by the MMS Client from the MMS Proxy -Relay is built upon the 
normal WSP/HTTP GET functionality. Therefore, no new operation is actually defined. The message type for the 
message returned from the MMS Proxy -Relay to the MMS Client is M- ret r i eve - conf . 

Delivery of the MM message MAY be either before or after the M-Noti fyResp . i nd message, depending on 
immediate retrieval or delayed retrieval of MM message respectively. The MMS Proxy -Relay MAY therefore decide 
to request an acknowledgement from the MMS Client to confirm successful retrieval in case of delayed retrieval. 
These variations are shown in Figure 9 and Figure 10 respectively. 



MMS 
Proxy-Relay 



MMuri 



•^ tn ' eve -conf 
MM multipart 



MMS 
Client 



Figure 9£xample MMS Retrieval Transaction without Acknowledgement 
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WSP/HTTP GET.req. 
MMuri 



MMmu/«part t tran s= T3- 



MMS 
Client 



M.Acknowledge.ind. 
trans=T3 

Figure 10. Example MMS Retrieval Transaction with Acknowledgement 



7.3.1 Transaction Flow 

The MMS Client SHALL initiate the retrieval activity by utilizing the URI that was delivered to it in the 
H-Noti f i cati on . i nd message using the connection oriented mode of the normal WSP/HTTP GET method 
operation. 



When setting up the WSP session and when sending the GET request the MMS Client SHOULD convey the 
capabilities of the terminal and of the MMS Client. For more details see section 8 on Terminal Capability 
Negotiation. 

The response message H- retrieve, conf, if successful, contains the MM message. This MM message 
SHALL include MMS headers providing additional information. 
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Depending on the MMS Proxy -Relay needs, the M- ret ri eve - conf response that it provides MAY request an 
acknowledgement to be generated by the MMS Client. The MMS Proxy -Relay MAY make this request based on 
whether or not it needs to provide a delivery notice back to the originator of the MM message. Alternatively, it 
MAY make that request based upon an expectation that it would then be able to delete the message from its own 
store. This decision is not a part of this transaction. 



The MMS Proxy Relay SHALL make this request for acknowledgement by including a transaction ID in the M- 
ret ri eve . conf message. This transaction ID is used by the MMS Client and MMS Proxy -Relay to provide 
linkage between the originated M-ret ri eve - conf and the response N-Acknowl edge - i nd messages. The 
value used for the transaction ID is determined by the MMS Proxy -Relay and no interpretation is expected by the 
MMS Client. 



If an acknowledgement is requested, the MMS Client SHALL respond by invoking a WSP/HTTP POST operation 
with an M-Acknowl edge, i nd message embedded as the content body. This message is submitted using a URI 
that addresses the MMS Proxy -Relay that supports the specific MMS Client. The MMS Client SHOULD ignore the 
associated WSP/HTTP POST response from the MMS Proxy -Relay. The H-Acknowl edge . i nd message 
confirms successful MM message retrieval to the MMS Proxy Relay. 

7.3.2 Error Considerations 

If the URI can not be resolved, a network or server fault MAY be returned. For example, if the MMS Server deletes 
the message from the store, making the requested message unavailable, it is expected that the WSP/HTTP request 
will generate a 'Data Not Available* status code (e.g. 404). In this case, the lower level error would be returned and 
no application level errors would be possible since no MM message data will be returned. 

7.3.3 Clarifications 



To some readers it may not appear consistent that the WSP/HTTP GET.req message is shown in Figure 9 and 
Figure 10 as this message belongs to a different protocol layer than the other messages. However, the figures are 
consistent in that they define the MMS Client Transactions in terms of the PDUs sent "across the wire" between 
peer entities (and not in terms of primitives, which are defined between layers in a protocol stack). The appearance 
of WSP/HTTP GET.req in the diagrams is not to be taken as a recommendation to bypass the implementation of 
layered protocols. 
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7.4 MMS Proxy-Relay Sending Delivery Report to MMS Client 

To permit the originating MMS Client to know when a message delivery has occurred the M-Del i very _ ind 
message has been defined to provide that information. The Pi-Delivery, i nd message originates at the MMS 
Proxy -Relay providing information to the MMS Client about the message that was delivered. There is no 
associated response or acknowledgment message. The following Figure 1 1 shows an example of this message. 



MMS 
Client 



MMS 
Proxy-Relay 



M-Deliveryjnd 
-*- r ef=MsglD. status, 



ess 



Figure 1 1 . Example Delivery Report 



7.4.1 Transaction Flow 

The M-Del i ve ry . i nd message SHALL be sent by the MMS Proxy -Relay to the MMS Client using the WAP 
PUSH framework [PUSHARCH]. The M-Del i very .ind message SHALL be sent as the message body of a 
[PUSHMSG]. The X-Wap-Application-Id message header of that push message MUST be set to 'x-wap- 
application:mms.ua , if the absoluteURI form of the app-id syntax is used, and MUST be set to '4* if the app- 
assigned-code form of the app-id syntax is used. 

The M-Del i ve ry . i nd message conveys information about the status of a particular message delivery that was 
performed. The message is identified by the Message ID that was generated when the original message was 
posted. It also provides addressing information of the originally targeted entity. 

If an MM message was addressed to multiple entities, multiple M-Del i ve ry - i nd messages SHOULD be 
expected to be returned, one for each addressed entity. 

7.4.2 Error Considerations 

The M-Del i ve ry . i nd message is generated when the MMS Proxy -Relay is satisfied that it has sufficient 
information to declare that the message was delivered or other status can be declared. As such, there may be cases 
where the MMS Proxy -Relay makes a decision about the delivery status that may be incorrect (e.g. timer expiry may 
generate an expiry notice but MMS Client may actually retrieve message if the read occurred before the message 
was deleted). 

There is no associated response or acknowledgment message defined for the M-Del i very . i nd message. The 
success rate for transmittal of the M-Del i ve ry . i nd message is dependent upon the quality of service provided 
by the transport service(s) utilized. 

7.4.3 Other Issues 

A target MMS Client may, within an M-Noti f y Resp - i nd message or an M-Acknowl edge . i nd message, 
request denial of an originator's request for delivery notification. Therefore, an MMS Client SHOULD NOT expect 
to receive all the M-Del i very . i nd messages that it may have requested. 
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7.5 Read Reports 

When the originating MMS Client requests the Read-Reply in a multimedia message, the receiving MMS Client 
MAY send a read message back to it. This message is sent and delivered using the normal mechanisms as 
described in this section. 

To permit a user to determine that a message is a read reply, a few fields can be used to provide that information: 

• The subject field SHOULD be copied from the original, prepending a 'Read:' to the text. 

• The Message-ID of the original message is available and SHOULD be included in the message body. 

• The body of the message MAY provide information about the read action or status. 

The following is an example of a read reply message. It is in response to a message that user A had sent to user B: 



From: B 
To: A 

Sent: Friday, January 21 , 2000 1 :50 PM 
Subject Read: My Message 
Your message 

To: B 

Subject: My Message 

Message-ID: <20000221 1 806.MAA26265@mail1 .domain.com> 
Sent: 1/21/2000 1:29 PM 

was read on 1/21/2000 1:50 PM. 



7.5.1 Transaction Flow 

If supported by a receiving MMS Client, the read reply message is sent to the MMS Proxy -Relay when an MM 
message has been read that had been flagged with the Read-Reply flag. The message SHALL be sent using the 
normal M-Send operation as it is just another message origination. As such, it SHALL be delivered using the 
normal delivery methods. Due to the nature of the message, the Message-Cl ass field SHALL have the value 
'Auto', the Read-Reply flag MUST NOT be set, and the Del i very-Report flag MUST NOT be set in a 
read-reply message. 

The MMS Client receiving a read reply message will see it as a new message. The interpretation as a read-reply is 
done by context. In cases where the original message had multiple addresses, the MMS Client SHOULD expect 
that multiple read-reply messages will be returned. 

7.5.2 Error Considerations 

Origination and delivery of a read-reply message is as for a normal message and does not require additional error 
considerations. 

7.5.3 Other Issues 

Since read-reply is an optional capability of the receiving MMS Client, an originating MMS Client SHOULD NOT 
depend upon receiving a read-reply in all cases. 
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7.6 Security Considerations 

Security aspects are considered outside the scope of this document and are not further discussed, except for the 
following paragraph. 

At present, the end-to-end security aspects of the MMS M PDUs are dependent upon the security provided by the 
transport service(s) utilized. 
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8. Terminal Capability Negotiation 

This section is normative. 

If the MMS Client performs capability negotiation then it MUST use the mechanism specified in [UAPROF]. The 
MMS Proxy Relay SHOULD support this mechanism. 



If using capability negotiation, the MMS Client SHALL indicate its capabilities within the UAProf information by 
using attributes from the MMS Characteristics component defined below and OPTIONALLY by using attributes 
from other components of the UAProf schema. The MMS Proxy-Relay SHOULD use this information in 
preparation of messages to be delivered to the MMS Client. 

The MMS Proxy -Relay MAY adjust a message to be delivered that contains media types that are not supported by 
the MMS Client. This adjustment MAY involve the deletion or adaptation of those unsupported media types. 

8.1 MMS attributes in other components of the UAProf schema 

This section is informative. 



The UAProf specification includes a schema containing attributes that describe the client hardware, the browser 
user-agent, network characteristics and more. Some of the attributes included in the aforementioned specification 
also apply to the MMS Client, e.g. "ScreenSize" "CpuType", and "PushMessageSize". For a complete reference to 
the attributes available in the UAProf schema, please see [UAPROF]. 



8.2 Summary of the MMS Characteristics component 

This section is informative. A normative description can be found in Appendix A. 1 . 

The table below summarizes the attributes defined within the MMS Characteristics component. 




MmsMaxMe s s age S i z e 



The maximum size of a 
multimedia message in bytes. 



Locked 



Number 



20480 



MmsMaxImageResoluti 
on 



The maximum size of an image 
in units of pixels 
(horizontal x vertical) . 



Locked 



Literal 



" 80x60" 



MmsCcppAccept 



List of supported content 
types conveyed as MIME types. 



Locked 



Literal 
bag 



"image/ jpeg", 
* audio/ wav" , 
"video/ mpeg - 4 " 



Mms Ccpp Ac c ep t Cha r 
Set 



List of character sets that 
the MMS Client supports. Each 
item in the list is a 
character set name registered 
with I ANA. 



Locked 



Literal 
bag 



•US -ASCII", 
"ISO-8859-1" 



Mms C cpp Ac c e p t L ang 
uage 



List of preferred languages . 
The first item in the list 
should be considered the 



Locked 



Literal 
bag 



"en" , 
"fr" 
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user's first choice. Property- 
value is a list of natural 
languages, where each item in 
the list is the name of a 
language as defined by 
[RFC1766] . 








MmsCcppAcceptEnco 
ding 


List of transfer encodings 
that the MMS Client supports. 
Property value is a list of 
transfer encodings, where each 
item in the list is a transfer 
encoding name as specified by 
[RFC2045] and registered with 
I ANA. 


Locked 


Literal 
bag 


"base64", 

"quoted- 

printable" 


MmsVersion 


The MMS versions supported by 
the MMS Client conveyed as 
ma j orVer s ionNumber . minorVers io 
nNumber . 


Locked 


Literal 
bag 


"2.0", "1.3" 
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9. Static Conformance Requirements 

The format, contents and syntax of the tables in this section are as mandated by [CREQ]. 

The SCR items in the "Requirement" column can be found in the following WAP specifications: 

• SCR items starting with "UAProf ' are defined in [UAPROF]. 

• SCR items starting with "MMSE" are defined in [MMSENC APS] . 

• SCR items starting with "MSG" are defined in [PUSHMSG]. 

• SCR items starting with "OTA" are defined in [PUSHOTA]. 

• SCR items starting with "WSP" are defined in [WAPWSP]. 

9.1 MMS Client 



9.1.1 Client Level Function Groups 





Function , : : 




Status 


Requirement . 


MMSCTR-CLF-C- 
001 


Support for MMS Client 
Functions 


7 


M 


MMSCTR-CLF-C-002 OR 
MMSCTR-CLF-C-003 


MMSCTR-CLF-C- 
002 


Support for Originating 
MMS Client Functions 


7.1, 
7.4 


O 


MMSCTR-SND-C-001 AND 
MMSCTR-DRP-C-001 


MMSCTR-CLF-C- 
003 


Support for Receiving MMS 
Client Functions 


7.2, 
73 


O 


MMSCTR-NTF-C-001 AND 
MMSCTR-FTOC-001 


MMSCTR-CLF-C- 
004 


Capability Negotiation 
between Receiving MMS 
Client and MMS Proxy -Relay 
using the UAProf 
Component MMS 
Characteristics 


7.3.1, 
8 


0 


MMSCTR-CLF-C-003 AND 
UAProf: MCF 



9.1.2 Send Transaction 



Item V. , l| ' \ 


inunction . . - ' - ; ; ... \ 


^Reference " 


v •' .. i^ - 
Status 


Requirement ; ; 


MMSCTR-SND-C- 
001 


Send Transaction between 
Originating MMS Client and 
MMS Proxy -Relay 


7.1 


O 


MMSCTR-SND-C-002 AND 
MMSCTR-SND-C-003 


MMSCTR-SND-C- 
002 


Originating MMS Client 
Sending M-Send.req to 
MMS Proxy -Relay 


7.1.1 


O 


MMSCTR-PDU-C-001 AND 
MMSCTR-WSP-C-001 


MMSCTR-SND-C- 
003 


MMS Proxy -Relay Sending 
M-Send.conf to Originating 
MMS Client 


7.1.1 


O 


MMSCTR-PDU-C-002 AND 
MMSCTR-WSP-C-002 
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Item 


Function 


Reference 


Status 


Requirement 


MMSCTR-NTF-C- 
001 


Notification Transaction 
between MMS Proxy -Relay 
and Receiving MMS Client 


12 


0 


M7vfSPTR-NTFXU)02 AND 
MMSCTR-NTF-C-003 


MMSCTR-NTF-C- 
002 


MMS Proxy -Relay Sending 
M-Notification.ind to 
Receiving MMS Client 


7.2.1 


0 


MMSCTR-PDU-C-003 AND 
MMSCTR-PSH-C-001 AND 
MMSCTR-PSH-C-002 AND 
MMSCTR-PSH-C-003 


MMSCTR-NTF-C- 
003 


Receiving MMS Client 
Sending M -Notify Resp.ind 
to MMS Proxy -Relay 


7.2.1 


0 


MMSCTR-PDU-C-004 AND 
MMSCTR-WSP-C-001 


9.1.4 Fetch Transaction 


Item 


-Function - 


Referenced 


Status 


Requirement: ^. r 


MMSCTR-FTC-C- 
001 


Retrieval Transaction 
between Receiving MMS 
Client and MMS Proxy -Relay 


7.3 


0 


MMSCTR-FTC-C-002 AND 
MMSCTR-FTC-C-003 AND 
MMSCTR-FTC-C-004 


MMSCTR-FTC-C- 
002 


Receiving MMS Client 
Sending Retrieve Request to 
MMS Proxy -Relay 


7.3.1 


0 


MMSCTR-WSP-C-003 


MMSCTR-FTC-C- 
003 


MMS Proxy -Relay Sending 
M-retrieve.conf to Receiving 
MMS Client 


7.3.1 


0 


MMSCTR-PDU-C-005 AND 
MMSCTR-WSP-C-004 


MMSCTR-FTC-C- 
004 


Receiving MMS Client 
Sending M- 

Acknowledge.ind to MMS 
Proxy -Relay 


7.3.1 


0 


MMSCTR-PDU-C-006 AND 
MMSCTR-WSP-C-001 


9.1 .5 Delivery Report Transaction 


Item 


Function 


Reference 


Status 


Requirement :\ 


MMSCTR-DRP-C- 
001 


Delivery Report Transaction 
between MMS Proxy -Relay 
and Originating MMS Client 


7.4 


0 


MMSCTR-DRP-C-O02 


MMSCTR-DRP-C- 
002 


MMS Proxy -Relay Sending 
M-Delivery.ind to 
Originating MMS Client 


7.4.1 


O 


MMSCTR-PDU-C-007 AND 
MMSCTR-PSH-C-001 AND 
MMSCTR-PSH-C-002 AND 
MMSCTR-PSH-C-003 
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■ansae <,.32i 




MBS 




MMSCTR-RRP-C- 
001 


Ability to Generate Read 
Report in Receiving MMS 
Client 


7.5, 
7.5,1 


0 


MMSCTR-SND-C-001 


MMSCTR-RRP-C- 
002 


Ability to Receive Read 
Report in Originating MMS 
Client 


7.5, 
7.5.1 


0 


MMSCTR-NTF-C-001 AND 
MMSCTR-FTC-C-001 


9.1.7 PDU Encapsulation Dependencies 






vReference^ 






MMSCTR-PDU-C- 
001 


Originating MMS Client 
Sending Encapsulated M- 
Send.req PDU to MMS 
Proxy -Relay 


7.1.1 


0 


MMSE-C-017 AND 
MMSE-C-018 AND 
MMSE-C-019 AND 
MMSErC-021 AND 
MMSErC-025 AND 
MMSE-C-034 


MMSCTR-PDU-C- 
002 


MMS Proxy -Relay Sending 
Encapsulated M-Send.conf 
PDU to Originating MMS 
Client 


7.1.1 


0 


MMSE-C-017 AND 
MMSE-C-018 AND 
MMSE-C-019 AND 
MMSE-C-035 AND 
MMSE-C-038 


MMSCTR-PDU-C- 
003 


MMS Proxy -Relay Sending 
Encapsulated M- 
Notification.ind PDU to 
Receiving MMS Client 


7.2.1 


0 


MMSE-C-039 AND 

"\yflVifCT3 z" 1 f\A(\ a xrp\ 

MMSE-C-041 AND 
MMSE-C-044AND 
MMSE-C-045 AND 
MMSE^C-046AND 
MMSErC-047 


MMSCTR-PDU-C- 
004 


Receiving MMS Client 
Sending Encapsulated M- 
NotifyResp.ind PDU to 
MMS Proxy -Relay 


7.2.1 


0 


MMSE-C-039 AND 
MMSE-C-040 AND 
MMSE-C-041 AND 
MMSE-C-048 


MMSCTR-PDU-C- 
005 


MMS Proxy -Relay Sending 
Encapsulated M- 
retrieve.conf PDU to 
Receiving MMS Client 


7.3.1 


0 


MMSE-C-050 AND 
MMSE-C-053 AND 
MMSE-C-054 AND 
MMSE-C-055 AND 
MMSE-C-056 AND 
MMSEC:-057 AND 
MMSE-C-060 AND 
MMSE-C-068 


MMSCTR-PDU-C- 
006 


Receiving MMS Client 
Sending Encapsulated M- 
Acknowledge.ind PDU to 
MMS Proxy -Relay 


7.3.1 


0 


MMSE-C-070 AND 
MMSE.C-072 
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MMSCTR-PDU-C- 
007 


MMS Proxy -Relay Sending 
Encapsulated M -Delivery, ind 
PDU to Originating MMS 
Client 


7.4.1 


0 


MMSE-C-070 AND 
MMSE-C-072 AND 
MMSE-C-074 AND 
MMSE-C-075 AND 
MMSE-C-076 AND 
MMSErC-077 


9.1.8 WAP PUSH Dependencies 




Function 


Reference 


Status 

. 


Requirement 


MMSCTR-PSH-C- 

ATI! 


MMS Proxy -Relay Using 
WAP PUSH Operation to 

\A\AO DTVTT \Jf\JfO 

bend MMo PDU to MMo 
Client 


7.2.1, 

T /| 1 

7.4.1 


O 


MMSCTR-PSH-C-004 OR 
MMSCTR-PSH-C-005 OR 
MMSCTR-PSH-C-006 OR 
MMSCTR-PSH-C-007 


MMot 1 K-rari-C- 
002 


rormat ana Contents or Push 
Message 


7.2.1, 
7.4.1 


0 


MSG-GEN-C-002 AND MSG- 
GEN-C-003 AND MSG-GEN-C- 
005 


MMSCTR-PSH-C- 
003 


Push Application 
Addressing and Dispatching 
to MMS Client 


7.2.1, 
7.4.1 


o 


OTA-GEN-C-002 AND OTA- 
GEN-C-003 


MMSCTR-PSH-C- 
004 


Non-secure Port for 
Connectionless Push 


7.2.1, 
7.4.1 


0 


OTA-CL^C-001 AND 
OTA-CL-C-002 


MMSCTR-PSH-C- 
005 


Secure Port for 
Connectionless Push 


7.6, 

7.2.1, 

7.4.1 


0 


OTA-CLrC-001 AND 
OTA-CL-C-003 


MMSCTR-PSH-C- 
006 


Non-secure Port for 
Connection Oriented Push 


7.2.1, 
7.4.1 


0 


OTA-CO-C-001 AND 
OTA-CO-C-004 


MMSCTR-PSH-C- 
007 


Secure Port for Connection 
Oriented Push 


7.6, 

7.2.1, 

7.4.1 


o 


OTA-CO-C-001 AND 
OTA-CO-C-005 


9.1.9 WSP/HTTP Dependencies 




Function 


Relerence 


Status 


Requirement 


MMSCTR-WSP-C- 
001 


MMS Client Using 
WSP/HTTP POST Request 
to Send MMS PDU to MMS 
Proxy -Relay j 


7.1.1, 
7.2.1, 
7.3.1 


0 


WSP-C-001 


MMSCTR-WSP-C- 
002 


MMS Proxy -Relay Using 
WSP/HTTP POST Response 
to Send MMS PDU to MMS 
Client 


7.1.1 


0 


WSP-C-001 
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MMSCTR-WSP-C- 
003 


MMS Client Using 
WSP/HTTP GET Request to 
Request MMS PDU from 
MMS Proxy -Relay 


73.1 


0 


WSP-C-001 


MMSCTR-WSP-C- 
004 


MMS Proxy -Relay Using 
WSP/HTTP GET Response 
to Send MMS PDU to MMS 
Client 


7.3.1 


0 


WSP-C-001 
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9.2 MMS Proxy-Relay 

9.2.1 Server Level Function Groups 













MMSCTR-SLF-S- 
004 


Capability Negotiation 
between Receiving MMS 
Client and MMS Proxy -Relay 
using the UAProf 
Component MMS 
Characteristics 


7.3.1, 
8 


0 


UAProf: MSF 


9.2.2 Send Transaction 




^um:Sbnt^£;^;^ ^ 


Referlriflfi 


'"Status 


Require inent -V'ST- 


MMSCTR-SND-S- 
001 


Send Transaction between 
Originating MMS Client and 
MMS Proxy -Relay 


7.1 


M 


MMSCTR-SND-S-002 AND 
MMSCTR-SND-S-003 


MMSCTR-SND-S- 
002 


Originating MMS Client 
Sending M-Send.req to 
MMS Proxy -Relay 


7.1.1 


0 


MMSE-S-078 


MMSCTR-SND-S- 
003 


MMS Proxy -Relay Sending 
M-Send.conf to Originating 
MMS Client 


7.1.1 


0 


MMSE-S-078 


9.2.3 Notification Transaction 






Reference 


^Status | 


■Requirement- 


MMSCTR-NTF-S- 
001 


Notification Transaction 
between MMS Proxy -Relay 
and Receiving MMS Client 


7.2 


M 


MMSCTR-NTF-S-002 AND 
MMSCTR-NTF-S-003 


MMSCTR-NTF-S- 
002 


MMS Proxy -Relay Sending 
M-Notification.ind to 
Receiving MMS Client 


7.2.1 


0 


MMSE-S-079 AND 
MMSCTR-PSH-S-002 


MMSCTR-NTF-S- 
003 


Receiving MMS Client 
Sending M-NotifyResp.ind 
to MMS Proxy -Relay 


7.2.1 


0 


MMSE-S-079 
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^ sir t ~ ; ' ' : 


Requirement U^V- 


MMSCTR-FTC-S- 
001 


Retrieval Transaction 
between Receiving MMS 
Client and MMS Proxy -Relay 


7.3 


M 


MMSCTR-FTGS-002 AND 
MMSCTR-FTOS-003 AND 
MMSCTR-FTC-S-004 


MMSCTR-FTC-S- 
002 


Receiving MMS Client 
Sending Retrieve Request to 
MMS Proxy -Relay 


7.3.1 


O 




MMSCTR-FTC-S- 
003 


MMS Proxy -Relay Sending 
M-retrieve.conf to Receiving 
MMS Client 


7.3.1 


o 


MMSE-S-080 


MMSCTR-FTGS- 
004 


Receiving MMS Client 
Sending M- 

Acknowledge.ind to MMS 
Proxy -Relay 


7.3.1 


0 


MMSE-S-080 


9.2.5 Delivery Report Transaction 


Item ■ : ; vj/ 


Function j 


Reference t 


Status 


Requirement . 


MMSCTR-DRP-S- 
001 


Delivery Report Transaction 
between MMS Proxy -Relay 
and Originating MMS Client 


7.4 


M 


MMSCTR-DRP-S-002 


MMSCTR-DRP-S- 
002 


MMS Proxy -Relay Sending 
M-Delivery.ind to 
Originating MMS Client 


7.4.1 


O 


MMSE-S-081 AND 
MMSCTR-PSH-S-002 


9.2.6 WAP PUSH Dependencies 


Item : ,•: • ■ . 


Unction '.. " 


Reference 


Status 


Requirement 1 ^ 


MMSCTR-PSH-S- 
002 


Format and Contents of Push 
Message 


7.2.1, 
7.4.1 


0 


MSG-GEN-S-002 AND MSG- 
GEN-S-003 AND MSG-GEN-S- 
005 
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Appendix A.1 . UAProf Schema for MMS Characteristics 

This section is normative. 

<?xral version= n 1 . 0" ?> 

<rdf:RDF xmlns:rdf = "http://www.w3.Org/TR/1999/02/22-rdf-syntax-ns##" 
xmlns:rdfs = "http://www.w3.Org/2000/01/rdf-schema#" 

xmlns:prf="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#"> 
<rdf : Description ID= 11 Component" > 

<rdf :type resource="http : //www.w3 . org/2000/01/rdf -schema#Class"/> 
<rdfs :subClassOf rdf : resource="http: //www. w3 . org/2000/01/rdf - 
schema#Re source " /> 
<rdf s : label >Component</rdfs : label > 
<rdf s : comment > 

A Component within the CC/PP Schema is a class of related 
properties that describe the capabilities and preferences 
information. 
</rdf s : comment > 
</rdf : Description 

< ! - - ****************************************************************** __ > 
<i-- ***** Properties shared among the components***** --> 

<rdf : Description ID= " component " > 

<rdf :type resource="http : //www. w3 .org/2 00 0/01 /rdf -schema#Property"/> 
<rdf s : label >component< /rdf s : label > 
< rdf s : comment > 

The component attribute links the various components to 

the root node (prof ile) . 
</ rdf s : comment > 
</rdf : Description 

< I - - ****************************************************************** __ > 

<!-- ***** component Definitions ***** 

<rdf : Description ID=" MmsCharacteristics" > 

<rdf : type resource="http : //www. w3 .org/2000/01/rdf -schema#Class"/> 

<rdf s : subClassOf rdf : resource="#Component"/> 

<rdf s : label >Component : MmsCharacteristics</rdf s : label > 

<rdf s : comment > 

The MmsCharacteristics component contains properties of the device 1 s 
Multimedia messaging capabilities, such as maximum message size, maximum 
image resolution, etc. 
</rdf s : comment > 
</rdf :Description> 

< 1 - - ****************************************************************** 
<!__ ***** component: MmsCharacteristics ***** --> 

< r - _ ****************************************************************** __ > 

***** Attributes for component: MmsCharacteristics ***** --> 
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<rdf : Description ID= "MmsMaxMessageSize" > 

<rdf : type rdf : resource="http: //www. w3 .org/2000/01/rdf -schema#Property M /> 
<rdf s : domain rdf : resource= " #MmsCharacteristics " / > 
<rdf s : comment > 
Description: Maximum size of an MMS message in bytes. 
Type : Number 
Resolution: Locked 
Examples: 2048 
</rdf s : comment > 
< / rdf : Description 

<rdf : Description ID= "MmsMaxImageResolution" > 

<rdf :type rdf :resource= n http: //www. w3 .org/2 000/01/rdf -schema#Property"/> 
<rdf s : domain rdf : resource= " #Mms Char act eristics " / > 
< rdf s : comment > 

Description : The maximum size of an image in units of pixels 
(horizontal x vertical). 
Type: Literal 
Resolution : Locked 
Examples: 80x60 
</rdf s : comment > 
</rdf : Description 



<rdf : Description ID= "MmsCcppAccept " > 

<rdf :type rdf : resource="http: //www.w3 .org/2000/0l/rdf -schema#Property"/> 
<rdf :type rdf : resource="http : //www. w3 .org/2 000/01/rdf -schema#Bag"/> 
<rdf s: domain rdf : resource="#MmsCharacteristics"/> 
< rdf s : comment > 

Description: Property value is a list of supported content types 
where each item in the list is a content type name 
registered as a MIME type 

Type : Literal bag 

Resolution: Locked 

Examples: "image/ j peg" , "audio/wav", "video/mpeg-4" 

< / rdf s : comment > 
</rdf : Description> 



<rdf description ID=" MmsCcppAccept CharSet" > 

<rdf :type rdf : resource="http : //www. w3 . org/2 000/01/rdf -schema#Property M /> 
<rdf :type rdf : resource="http : //www. w3 . org/2000/01/rdf -schema#Bag"/> 
<rdfs: domain rdf : resource=" #MmsCharacteri sties "/> 
<rdf s : comment> 

Description: List of character sets that the MMS Client supports. 

Property value is a list of character sets, where 

each item in the list is a character set name registered 

with I ANA 

Type: Literal bag 

Resolution: Locked 

Examples: "US-ASCII" , "ISO-8859-1" 

</rdf s : comment > 
</rdf :Description> 

<rdf : Description ID=" MmsCcppAccept Language "> 

<rdf : type rdf : re source = M http: //www. w3 . org/2 000/01/rdf -schema#Property"/> 
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<rdf :type rdf : resource="http : //www.w3 .org/2000/0l/rdf -schema#Bag"/> 
<rdf s rdomain rdf :resource= ,, #MmsCharacteristics"/> 
< rdf s : comment > 

Description: List of preferred languages. The first item in the 
list should be considered the user's first choice. 
Property value is a list of natural languages, where 
each item in the list is the name of a language as 
defined by RFC 1766. 

Type: Literal bag 

Resolution: Locked 

Examples: "en", n fr" 

< / rdf s : comment > 
</rdf : Description 

< rdf description I D= "MmsCcppAccept Encoding "> 

<rdf : type rdf :resource="http: //www.w3 .org/2000/01/rdf -schema#Property H /> 
<rdf : type rdf : resource= "http : / /www . w3 . org/ 2000/0 1 /rdf - schema#Bag " / > 
<rdfs: domain rdf :resource="#MmsCharacteristics n /> 
<rdfs: comment > 

Description: List of transfer encodings that the MMS Client supports. 

Property value is a list of transfer encodings, where 
each item in the list is a transfer encoding name as 
specified by RFC 2045 and registered with I ANA . 

Type: Literal bag 

Resolution: Locked 

Examples : "base64" , "quoted-printable" 

</rdf s : comment > 
</rdf :Description> 

<rdf : Description ID="Mms Vers ion" > 

<rdf : type rdf : resource= "http : //www . w3 . org/2 00 0/01 /rdf -schema#Property " /> 
<rdf : type rdf : resource= "http : //www . w3 . org/2000/01/rdf -schema#Bag" /> 
<rdf s : domain rdf : resource= " #MmsCharacteri sties " / > 
<rdf s : comment > 

Description: The MMS versions supported by the MMS Client conveyed 

as ma j orVersionNumber . minorVers ionNumber . 
Type: Literal bag 

Resolution: Locked 
Examples: "2.0", "1.3" 

< / rdf s : comment > 
</rdf : Description 

</rdf :RDF> 
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Appendix A.2. History and Contact Information 



Document history 


Date 


Description 


12 Apr 2001 


Initial proposed version. 


12 Jun 2001 


Initial approved version. 

Incorporates SCD WAP-206_100-MMSCTR-20010612. The changes are in Appendix A. 1 UAProf 
Schema for MMS Characteristics. 

• All but one of the URLs that have www.w3.orc as server are changed to reflect new and 
approved version 2000 URLs. 

• The URL to the MMS profile on the www.wapforum.ore server is changed to include 
"/profiles" in the path. 

• All 'Bag' URLs are now enclosed in double quotes. 


09 Oct 2001 


Incorporates the Class 3 SIN WAP-206_101-MMSCTR-200 11009. The changes are in section 9, 
"Static Conformance Requirements." Some of the WAP specifications referenced by WAP-206- 
MMSCTR-20010612-a used incorrect syntax for SCR items. These SCR syntax errors have been 
fixed in the referenced specifications. Therefore this version-updates the SCR Requirements 
column of a number of SCR items to match those fixes. 


Contact Information 

httD.V/www.waDforum.ora. 
Technical.comments(S)waDforum.ora 
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